AWS Bactch 指定した最大 vCPU 数を超える vCPU を持つインスタンスタイプが起動するのはなぜでしょうか？

大村保貴

2024.03.09

AWS Batch では指定した最大 vCPU 数を超える vCPU を持つインスタンスタイプが起動することもあります。どういった条件の場合に指定した最大 vCPU 数を超えるインスタンスタイプが起動してくるのか検証した結果を共有します。

確認結果

ユーザーに代わり適切なインスタンスタイプを選定してくれる配分戦略により、下記の条件下では最大 vCPU 数を超えるインスタンスタイプが起動してくる可能性があります。悪い動作ではなく配分戦略が上手くやってくれた結果です。

「許可されたインスタンスタイプ」に最大 vCPU 数を指定した vCPU 数より大きな vCPU 数を持つインスタンスタイプが含まれている
配分戦略はBEST_FITかつ、オンデマンド起動以外でコンピューティング環境を作成している

配分戦略	オンデマンド起動	スポット起動	備考
BEST_FIT	なし	可能性あり	-
BEST_FIT_PROGRESSIVE	可能性あり	可能性あり	-
SPOT_CAPACITY_OPTIMIZED	-	可能性あり	スポットのみ選択可能な配分戦略
SPOT_PRICE_CAPACITY_OPTIMIZED	-	可能性あり	同上

ジョブを実行して検証

AWS Batch でマネージド EC2 タイプのコンピューティング環境を利用して検証します。コンピューティング環境のスポットインスタンスを使い最大 vCPU 数は 8 とし、配分戦略はSPOT_CAPACITY_OPTIMIZEDを選択しています。使用 EC2 は C 系のインスタンスタイプをfamily指定しています。

1 つのジョブに必要な vCPU 数は 8 と定義したジョブを 100 件登録しました。

vCPU 数 16 個のc5.4xlargeが 1 台起動してきました。

最大 vCPU 数が 8 指定のコンピューティング環境なのに 16 vCPU のインスタンスが起動しました。さてどういうことなのでしょうか？

ドキュメント確認

今回指定したSPOT_CAPACITY_OPTIMIZED配分戦略の場合、最大 vCPU 数を超えるインスタンスが起動する可能性があるとのことです。

With BEST_FIT_PROGRESSIVE, SPOT_CAPACITY_OPTIMIZED, and SPOT_PRICE_CAPACITY_OPTIMIZED allocation strategies using On-Demand or Spot Instances and the BEST_FIT strategy using Spot Instances, AWS Batch might need to exceed maxvCpus to meet your capacity requirements. In this event, AWS Batch never exceeds maxvCpus by more than a single instance. For example, AWS Batch uses no more than a single instance from among those specified in your compute environment.

Compute environment parameters - AWS Batch

ということがわかったのですが、文章だと理解しにくいので上記の内容を表にして整理しました。

配分戦略	オンデマンド起動	スポット起動	備考
BEST_FIT	なし	可能性あり	-
BEST_FIT_PROGRESSIVE	可能性あり	可能性あり	-
SPOT_CAPACITY_OPTIMIZED	-	可能性あり	スポットのみ選択可能な配分戦略
SPOT_PRICE_CAPACITY_OPTIMIZED	-	可能性あり	同上

つまり、オンデマンド起動で配分戦略をBEST_FIT選択したとき以外は、最大 vCPU 数を超えたインスタンスタイプを起動する可能性があります。前提としてコンピューティング環境の「許可されたインスタンスタイプ」で選択されていないインスタンスタイプは起動してきません。

今回の場合であれば、許可されたインスタンスタイプで 8 vCPU 以下のインスタンスタイプを選択していれば指定した最大 vCPU 数を超過するインスタンスが起動することはありえませんでした。

最大 8 vCPU の実行環境で 1 ジョブあたり 8 vCPU 指定のジョブを処理するのであれば、8 vCPU きっかりのインスタンスタイプが起動してくることが理想的にも思えます。

計算リソースの観点からみると 8 vCPU のインスタンスを利用する方が経済的と言えるでしょう。ですが、スポットインスタンスであれば vCPU 数の数の多いインスタンスタイプでも安く起動できる可能性あります。その辺をユーザーに代わりよしなにやってくれるのが「配分戦略」のお仕事なので、今回の様にワンサイズ大きな 16 vCPU のインスタンスタイプが起動するのは意図した動作でした。

ジョブ処理の挙動について検証してみた

今回の検証では 1 つのジョブに必要な vCPU 数は 8 指定したジョブを 100 件登録したため、ジョブキュー全体で処理に必要な vCPU 数は 800 vCPU となりました。最大 vCPU 数は 8 と指定している実行環境で、16 vCPU のインスタンスが起動したため、キュー内のジョブをどう処理していくのか観察してみました。

キュー内のジョブを捌くためにどんどんインスタンスが起動してくるのか？

vCPU 数 16 のインスタンスが 1 台起動してきましたが、それ以上のインスタンスは起動してきませんでした。

あくまでもジョブを処理するために必要なインスタンスを起動するときに、指定された最大 vCPU 数を超えるインスタンスタイプが選択され起動する可能性があるだけのようです。でなければ無制限にインスタンスが起動するため理に適っています。

大きなインスタンスタイプが起動したらしたでその分をｖCPU を有効活用してくれるのか？

今回は 16 vCPU のインスタンスが起動してきました。1 ジョブあたり 8 vCPU 指定のジョブですので、計算リソース的には 8 vCPU 分の余力があるはずです。残りの計算リソースを有効活用してくれるのか気になりました。

結果は有効活用していました。今回は 2 つジョブ（合計 16 vCPU 必要）を 1 台のインスタンスで同時に処理してくれました。

仮に 8 vCPU のインスタンスが起動してきた場合、1 つのジョブが終わったら、次のジョブの計算をする流れになります。今回は 2 つのジョブを並列処理されため、全体の実行時間は半分に短縮されるかたちとなりました。とは言え後続のジョブも 8 vCPU 必要なジョブだったため、16 vCPU のインスタンスでうまくハマっただけです。後続のジョブが仮に 9 vCPU 必要であれば 1 ジョブ毎の順次処理になっていたことでしょう。

ちなみにキュー内でジョブの重み付けして処理順序を調整するならスケジュールポリシーの設定をすることになります。

検証結果まとめ

下記の条件下では最大 vCPU 数より大きなインスタンスタイプが起動してくる可能性がありました。

「許可されたインスタンスタイプ」に最大 vCPU 数を指定した vCPU 数より大きな vCPU 数を持つインスタンスタイプが含まれている
配分戦略はBEST_FITかつ、オンデマンド起動選択以外でコンピューティング環境を作成している

配分戦略	オンデマンド起動	スポット起動	備考
BEST_FIT	なし	可能性あり	-
BEST_FIT_PROGRESSIVE	可能性あり	可能性あり	-
SPOT_CAPACITY_OPTIMIZED	-	可能性あり	スポットのみ選択可能な配分戦略
SPOT_PRICE_CAPACITY_OPTIMIZED	-	可能性あり	同上